Expand kinematics introduction with why/when guidance #3143
+60
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Added 'Why use kinematics and odometry' section explaining benefits - Enhanced autonomous performance discussion (path following, position tracking) - Field-oriented control benefits for holonomic drives - Trajectory generation and common use cases - Added 'When to use each drivetrain type' section - Differential drive: best for traction, pushing power, simpler builds - Swerve drive: maximum maneuverability, most complex - Mecanum drive: holonomic with simpler mechanics than swerve - Added important considerations (drift, sensors, accuracy) - Links to example code for each drivetrain type Fixes wpilibsuite#1291
katzuv
reviewed
Oct 11, 2025
|
|
||
| ## Important considerations | ||
|
|
||
| **Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy. |
There was a problem hiding this comment.
Suggested change
| **Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy. | |
| **Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots and field elements. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy. |
| - Gyroscope for measuring robot angle (critical for accurate odometry) | ||
| - For swerve: absolute encoders for module angles | ||
|
|
||
| **Autonomous period accuracy**: Odometry is typically very accurate during autonomous (15 seconds) because there's less robot-to-robot contact. Estimates may drift more during teleoperation. |
There was a problem hiding this comment.
Suggested change
| **Autonomous period accuracy**: Odometry is typically very accurate during autonomous (15 seconds) because there's less robot-to-robot contact. Estimates may drift more during teleoperation. | |
| **Autonomous period accuracy**: Odometry is typically very accurate during autonomous (15 seconds) because there's less robot-to-robot contact. Estimates may drift more during teleop. |
Using language from the manual. TELEOP is in the glossary for "the Teleoperated Period".
|
Perhaps the comparison between different drivetrain types fits more elsewhere? |
sciencewhiz
reviewed
Oct 15, 2025
|
|
||
| **Match strategy**: Plan routes that avoid defense, optimize cycle times, coordinate with alliance partners | ||
|
|
||
| ## When to use each drivetrain type |
There was a problem hiding this comment.
It feels really out of place to talk about drivetrain selection in kinematics/odometry. The drivetrain selection should drive the code, and these characteristics have nothing to do with kinematics or odometry.
| - Requires precise module control and calibration | ||
| - Can use high-traction wheels | ||
|
|
||
| **Example code**: See the SwerveBot and SwerveControllerCommand examples in :doc:`/docs/software/examples-tutorials/wpilib-examples` |
There was a problem hiding this comment.
Given wpilibsuite/allwpilib#5098 I'm not sure I'd recommend the WPILib examples.
| ### Mecanum Drive | ||
|
|
||
| **Best for:** | ||
| - Teams wanting holonomic drive with simpler mechanics than swerve |
There was a problem hiding this comment.
Due to the slipping problem, I think the simpler mechanics is more theoretical then practical
| **Odometry drift**: Position estimates accumulate error over time, especially during physical contact with other robots. This is normal and expected. Vision-based corrections (using AprilTags) help maintain accuracy. | ||
|
|
||
| **Sensor requirements**: All kinematics implementations require: | ||
| - Encoders for measuring wheel/module speeds and positions |
There was a problem hiding this comment.
What's the reasoning for mentioning module speeds and positions? Isn't module speed the same as wheel speed and module position is covered below.
| - Robots that benefit from strafing but don't need maximum pushing power | ||
| - When compactness is important | ||
|
|
||
| **Characteristics:** |
There was a problem hiding this comment.
Can you do accurate odometry on mecanum? Or do you need vision?
There was a problem hiding this comment.
I think this depends on:
- What do you consider accurate? Its tolerances are not good compared to other options but if you need broad strokes movement like in some shooting games it is just fine without.
- A dead wheel significantly helps. It adds complexity but not having one can give more inconsistent results
- How complex is the movement and at what speeds?
There was a problem hiding this comment.
It was statements like these that make me question. https://www.chiefdelphi.com/t/end-of-mecanum-drive/433615/119
|
|
||
| **Self-correction**: Combined with vision systems (like AprilTag detection), odometry can be continuously updated to correct for drift and maintain accuracy throughout a match. | ||
|
|
||
| ### Field-Oriented Control |
There was a problem hiding this comment.
Is this really related to kinematics and odometry?
|
|
||
| **Vision-assisted driving**: Use AprilTags or other vision targets to update odometry and drive to precise field locations | ||
|
|
||
| **Teleoperation enhancement**: Field-oriented control for intuitive driving of holonomic robots |
There was a problem hiding this comment.
other then gyro, you don't need kinematics or odometry for field oriented control, right?
Changes based on reviewer feedback:
1. Removed "When to use each drivetrain type" section - reviewers felt
drivetrain selection should drive code choice, not vice versa, and
these characteristics aren't directly related to kinematics/odometry
2. Removed "Field-Oriented Control" section - field-oriented control
doesn't require full kinematics/odometry (just gyro), so it was
misleading to include here
3. Replaced WPILib example references with vendor examples that follow
best practices:
- CTRE Phoenix6 examples (differential and swerve with PathPlanner)
- REV MAXSwerve Template
- YAGSL (Yet Another Generic Swerve Library)
This addresses allwpilib#5098 which notes WPILib swerve examples
use quadrature encoders instead of absolute encoders
4. Added mecanum odometry accuracy considerations including:
- Wheel slipping issues
- Benefits of dead wheels for improved accuracy
- Vision-based correction recommendations
5. Applied minor wording improvements:
- Added "and field elements" to odometry drift explanation
- Changed "teleoperation" to "the Teleoperated Period" per manual glossary
- Simplified sensor requirements to remove confusing "module speeds
and positions" wording
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Significantly expands the kinematics introduction article to address issue #1291 by explaining why teams should use kinematics/odometry and when to choose each drivetrain type.
Changes
New "Why use kinematics and odometry?" Section
New "When to use each drivetrain type" Section
Differential Drive:
Swerve Drive:
Mecanum Drive:
Important Considerations
Impact
This expansion transforms the article from a purely technical reference into a practical guide that helps teams:
Fixes #1291